The present invention relates to the field of web based programs, and in particular to a method and system for performing the lifecycle management such as deployment, instantiation, running and removal of a web based application.
In FIG. 1 (Prior Art), a zoom-out view to a Portal server and a business user using a composite web application is given. The user interacts with a portal page 10 as one application. The portal page itself is composed out of different portlets 12A-G that may connect to different back end systems 14 to 20. For example back end systems can include a computer Customer Relationship (CRM) system 14, a Supply Chain Management (SCM) system 15, a content management system 16, a collaboration system 17, a medical workflow system 18 using electronic Health Records (eHR), a syndicated Content system 19, and a web services system 20. A portal server integrates these portlets on different levels (e.g., by allowing to exchange events or single sign-on) into one consistent composite application to the end-user.
Prior art composite applications allow to group together different artifacts such as portlets, pages, wires, communities, back-end services, into one package that can be installed and deployed as one artifact. The prior art implementations of composite applications deal with composite applications on a artifact level that allows users to create the different artifacts, such as portlets and pages, and then group these artifacts together into one composite application.
FIG. 2 (Prior Art) illustrates the most basic structural components of a prior art hardware and software environment used for a prior art method of lifecycle management. The lifecycle is depicted to extend from left to right covering some “columns”, beginning with deployment, continuing with Instantiation, Runtime, (i.e., execution), and finally the removal of the web based application. Each lifecycle stage (i.e., each column) uses the functional components, or tools as depicted at the left hand margin of the figure, as row indications. These are custom or standard services, a skeleton process, custom plug-in processes, application roles, membership roles, and Portal roles. At the cross point for a given column and row the tool or person, respectively, is indicated which is required to do the respective work.
One prior art technology in this area is defined by so-called OSGi Bundles, that define well-known methods for managing the lifecycle of an application after deployment (start, stop, update). However, these lifecycle methods do not deal with deployment, backup or error recovery with compensation models.
Since the composite applications, which are based on a set of common services, can integrate and require arbitrary other services, an installation support on the server, as for example for J2EE applications, is not sufficient for this job. As can be seen especially on the JavaEE example, this prior art approach leads to the limitation, that servers can only consume well defined applications. If the application needs more support than currently defined, all servers need to be updated to support the new definitions. Thus, having the installation controlled only by the consuming server is too limiting for composite applications. To solve this problem, the installations steps could theoretically be placed in the composite application. This of course leads to a great overhead in the composite applications, since standard installation steps would be needed to be added to each composite application.
To avoid both disadvantages, in general one could expect the installation support to be distributed across server and composite application. Sometimes even this would not be sufficient, in the case the installation of additional backend systems is required, which can not be controlled by the composite application itself. In this case it might be required, that both installations are done in parallel steps, which interact with each other. This, however, leads to situations, where one has to document complex manual procedures. Further, a lot of business application users fail, since the complexity can not be handled easily enough.
Thus, in summary, the disadvantage exists that there is much work to be done manually, which requires a lot of skill of the person doing this. Further, the work is error prone because there are in general many details to be considered when managing the whole lifecycle of a web based application.